On Mon, 26 Sep 1994, Fred Blonder wrote: > From: John Hawkinson <jhawk@panix.com> > > . > . > . > > The "correct" thing to do is to patch kern_exec.c (kern_exec.o). > > . > . > . > > Ummm, then how's it going to cope with set-uid perl scripts, which ARE > rumored to be secure? You could have a table of 'ok shell > interpreters' in the kernel, but that would be extremely ugly. > > Since the problem is in /bin/sh, that is where it should be solved, or > at least avoided. If you across-the-board disable all set-uid shell > interpreters, that will infuriate the few who do it right, and remove > any motivation for others to do it correctly. > ----- on many(most?) BSD based systems(don't know about SysV) - there is a race condition for shell scripts - that is independent of the interpreter which means any executable suid starting with #! is vulnerable (this involves soft links & switching the executed scripts) the way perl solves is ( on systems where setuid script are disabled ) is via executing a setuid version of the interpreter ( if suid is set on the *script* ) - this has nothing to do with security /bin/sh .... quoting from the perl manpage: - Setuid Scripts Perl is designed to make it easy to write secure setuid and setgid scripts. Unlike shells, which are based on multiple substitution passes on each line of the script, perl uses a more conventional evaluation scheme with fewer hidden "gotchas". Additionally, since the language has more built-in functionality, it has to rely less upon external (and possibly untrustworthy) programs to accomplish its pur- poses. In an unpatched 4.2 or 4.3bsd kernel, setuid scripts are intrinsically insecure, but this kernel feature can be dis- abled. If it is, perl can emulate the setuid and setgid mechanism when it notices the otherwise useless setuid/gid bits on perl scripts. If the kernel feature isn't disabled, perl will complain loudly that your setuid script is insecure. You'll need to either disable the kernel setuid script feature, or put a C wrapper around the script. When perl is executing a setuid script, it takes special precautions to prevent you from falling into any obvious traps. (In some ways, a perl script is more secure than the corresponding C program.) Any command line argument, environment variable, or input is marked as "tainted", and may not be used, directly or indirectly, in any command that invokes a subshell, or in any command that modifies files, directories or processes. Any variable that is set within an expression that has previously referenced a tainted value also becomes tainted (even if it is logically impossible for the tainted value to influence the variable). [etc,etc...] Rafi Sadowsky rafi@tavor.openu.ac.il [postmaster@openu.ac.il] FAX: +972-3-6460483